A typical Internet network implementation comprises a Service Provider Network (SPN) connected to a plurality of customer data facilities, commonly referred to as Customer Premises Equipment (CPE). The SPN is operated by an Internet Service Provider (ISP), and comprises a network Provider Edge (PE) nodes (for example, routers and/or IP switches). Each PE node is connected to one or more instances of CPE by access links. The PE nodes are connected within the SPN directly, via other nodes and via route reflectors. Each CPE may comprise a computer or network of computers operated by a customer, the computers being interconnected, for example, by a Local Area Network (LAN). Virtual Private Networks. A VPN is an emulated multi-site wide area routed network using IP facilities which are operated and implemented by an Internet Service Provider (ISP). Thus an SPN can be used to “connect” CPE across multiple sites. These “connections” are shared in the sense that the same PE nodes can be used to connect the CPE of more than one customer. Typically, a VPN is operated by establishing tunnels between Provider Edge (PE) devices supporting the sites of a VPN.
The Internet Engineering Task Force (IETF) is an industry consortium which seeks to define standards for implementation of Internet networks. Participants submit Internet Drafts to the IETF for discussion in working groups. Some proposals contained in Internet Drafts may eventually be adopted as standards by the IETF. Copies of Internet Drafts are available at Internet address ftp://frp.ietf.org/internet-drafts.
Recent IETF drafts make proposals concerning the implementation of Virtual Private Networks (VPNs) in SPNs using Multi-Protocol Label Switching (MPLS). Such drafts include:                {1} J. Heinanen et al, “VPN Support with MPLS”, <draft-heinanen-mpls-vpn-01.txt>, March 1998.        {2} D. Jamieson et al, “MPLS VPN Architecture”, <draft-jamieson-mpls-vpn-00.txt>, August 1998.        {3} T. Li, “CPE Based VPNs using MPLS”, <draft-li-mpls-vpn-00.txt>, October 1998.        {4} E. Rosen et al, “BGP/MPLS VPNs”, <draft-rosen-vpn-mpls-00.txt>, November 1998.        
To implement VPNs on SPNs using MPLS, {3} proposes that a CPE will transmit a Border Gateway Protocol (BGP) message to the SPN to indicate its presence in the network and to indicate the set of VPNs in which the CPE wants to participate. The BGP message includes “VPN reachability information”, including the CPE's address in the ISP's address space and a VPN identifier.
The BGP message is received by the PE node which is connected to the CPE. The PE node can filter or otherwise examine the message to ensure that it complies with the ISP's policies. If the message does comply with the ISP's policies, the message is propagated to other PE nodes of the SPN according to the specifications of BGP (see IETF document RFC 1771).
The other PE nodes of the SPN store the VPN reachability information and forward the BGP message to any of their connected CPE that are participating in the same VPN. The CPE receiving the BGP message can then use MPLS signalling protocol to set up a MPLS tunnel to the CPE which has just joined the VPN. The PE nodes use the stored VPN reachability information to establish the MPLS tunnels.
The method described in {3} requires very little or no intervention by an ISP when a new CPE is added to a VPN. However, in a large SPN which supports a large number of VPN subscribers, each PE node of the SPN would be required to store a very large amount of VPN reachability information. Moreover, only a small percentage of the stored VPN reachability information may actually be needed by any particular PE node.
For example, in an SPN having 2000 PE nodes and 1000 VPN interfaces per PE node with an average of 10 sites per VPN, 2 million VPN reachability information records would be distributed to each PE node. Assuming conservatively that each VPN reachability information record requires 30 bytes of storage, the VPN reachability information would require 60 Mbytes of storage at each PE node. However, according to the above assumptions, only 10,000 of the stored VPN reachability information records would actually be used by a typical PE node to establish VPN tunnels. The remaining 1.99 million of the 2 million reachability information records, stored at a typical PE node, i.e. 99.5% of the stored records, would not be used.
{4} proposes that PE nodes transmitting BGP messages apply outbound filtering so as not to propagate VPN reachability information to other PE nodes which are not participating in the VPN identified in the BGP message. Alternatively, {4} proposes that PE nodes receiving BGP messages apply inbound filtering so as not to store VPN reachability information for VPNs in which they are not participating. These filtering approaches may address the storage inefficiencies noted above. However, should CPE requiring access to a particular VPN be connected to a PE node not previously participating in that VPN, such filtering would result in the PE node lacking VPN reachability information for that VPN. The required VPN reachability information would need to be provided to the PE node, either by operator provisioning or by dropping and re-establishing the connection between the PE node and other PE nodes of the SPN so that all other PE nodes of the SPN automatically transmit all of their accumulated VPN reachability information to the PE node. The former method for acquiring the required VPN reachability information is time-consuming, error-prone and expensive. In a large network, the latter method for acquiring the required VPN reachability information would take too long and have too great an impact on SPN performance to be acceptable.